מה יותר מהיר, serialize או json_encode, לבדוק שהקובץ קיים או פשוט לעשות require_once ועוד כמה טיפים של איזה קוד עובד יותר מהר
הכללתי ברשימה הקצרה רק דברים שמפתיעים מתכנתים מתחילים ולא כללתי דברים
ברורים מאליו כמו שימוש בגרש יחידה במקום גרשיים כפולות למחרוזות ודומיהן.
אני מקווה שמישהו יצא מכאן עם משהו חדש.
התוצאות ומסקנות נשענות על בסיס של ניסויים בכמה גרסאות php
5.2.6 debian lenny, 5.3.2 של ubuntu, ו 5.2.14 של dotdeb.
אולי על פלאטפורמות אחרות יש הבדלים.
file_get_contents
הפונקציה הנחמדה הזו משתמשת במיפוי זיכרון מה שמביא לגידול בולט בביצועים, באיחוד בקבצים גדולים. המשמעות היא ש:
simplexml_load_string (file_get_contents ('file.xml'));
עובד יותר מהר מ:
simplexml_load_file('file.xml');
נראה כי הפונקציה simplexml_load_file מתבססת על fopen / fread קונבנציאונאלי, מה שמוביל להבדל במהירות.
נ.ב. עדיף להישתמש בזה לא רק בפונקציות של xml , הרי גם פונקציות אחרות יאיצו כתוצאה.לדוגמא, אם אתם מנסים לקרוא קובץ ולהפריד אותו לפי שורות לתוך מערך, אזי עדיף להחליף את file() ב
explode(PHP_EOL, file_get_contents('file.xml'));
()count ו ()sizeof
sizeof היא כינוי(פסאודונים) לפונקציה count אך משום מה היא עובדת מהר יותר.
שגיאות ו notices
להרשות לאפליקציה לזרוק notice הוא אחד המנהגים הגרועים ביותר בעולם התכנות. אפליקציה טובה יודעת להתמודד עם שגיאות בעצמה.
אבל אם אתם לא מוכנים לקבל על עצמכם את החשיבות במניעת שגיאות, פשוט דעו לכם
שהזמן הדרוש לphp להתמודד עם שגיאה גדול מהזמן שיקח לכם לרוץ על מערך עם 30 אלמנטים ולהגדיל כל אחד מהאלמנטים שלו באחד.
אגב השימוש ב @ היא קטסטרופה כדרך למניעת שגיאות.
כן והיא גם הרבה יותר איטית מהוספה של בדיקה האם המשתנה קיים למשל.
foreach
בכל מאמר על ביצועים דואגים לומר את הדברים הכי גרועים על foreach
למרות שבפועל לא הכל כל כך רע. הרבה פעמים מבנים שאנשים מנסים לכתוב כתחליף, דוגמאת:
while (list($key, $value) = each($item))
פועלים הרבה יותר לאט וגרוע בכ-30 -40 אחוז.
אך עדיין שימו לב, אם יש באפשרותכם להשתמש ב for אזי הוא יהיה עדיף על foreach
JSON vs XML
אוסיף כאן רק שאחרי מעבר לקבצי json לשמירת הגדרות במקום xml הרווחתי 20%-30% בביצועים. json נעים לעין, איאררכי ומהיר.
json_decode עובדת יותר מהר עם פרמטר אחד (כאשר יוצרת אובייקט ולא מערך)
mb_ereg vs preg_match
ביטויים רגולריים בדרך כלל משתמשים במנוע ה-posix .כדי לקרוא ולפענח מחרוזות. מנוע ה-posix ידוע באיטיות שלו, לכן
מנוע oniguruma שבו משתמשת mb_ereg לרוב יהיו בחירה טובה יותר לחייפ הרגולריים שלכםץ
בערך בשניים מתוך שלושה מקרים mb_ereg יעקוף בביצועים את preg_match
file_exists & include
אם אתם לא בטוחים שהקובץ קיים (autoload__ למשל) תועילו לעצמכם לבדוק האם הקובץ קיים לפני שאתם עושים לו אינקלוד.
עוד בקשר לאינקלוד: משום מה, לשמור במערך את שמות הקבצים שכבר הוספו יותר אפפקטיבי מלהשתמש ב include_once ולא באמת ברור לי למה.
(כל האמור תקף גם לrequire)
Static vars
הדרך הטובה והבטוחה לשמור נתונים בשדה הרעיה הגלובאלי היא בתוך משתנים סטאטיים של מחלקה כלשהי. כייון שהם סטאטיים php יודעת לנהל אותם הרבה יותר טוב מכל משתנה במחלקה או לא במחלקה שהוא. שימו לב, לרוב השימוש בקבועים constants הוא איטי נורא, לכן עדיף להימנע מכך במידת האפשר.
כמה המלצות לסיום
תציגו לעצמכם את זמן הפעולה של סקריפט במילישניות. עם שינוי כזה בקנה המידה
רואים את ההבדל בין "התבצע ב0.1 שניות" לאומת "התבצע ב100 מילישניות" .
גם קריא יותר וגם יעלה לכם את המוטיבציה לשפר עוד קצת.
מאוד חשוב לאסוף מידע לא רק אודות הביצוע של הסקריפט כולו אלה גם של חלקים נפרדים שלו: גרעין, אינטרפייס, רנדרינג, ועוד את הפרופיילר שלי קינפגתי (בשרת הבדיקות) לזרוק שגיאה כאשר קטע כלשהו לוקח זמן רב מדי מהצפוי:
"Attention!: 30% of the time taken for mysql connection"
כל המסקנות נלקחו מבדיקות במערכת שלי ויכול להיות שתתקלו בתוצאות שונות אצלכם.